Method for user plane connection activation or deactivation per session

ABSTRACT

This disclosure provides a User Equipment (UE), including: a transmitter configured to transmit at least one Protocol Data Unit (PDU) session identifier (ID), each of which indicates a PDU session that the UE needs to use in a Non Access Stratum (NAS) Service Request message to a Mobility Management Function (MMF) via an access network (AN) node when the UE has user data to send.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/205,848 filed on Mar. 18, 2021, which is a continuation of U.S.patent application Ser. No. 16/321,304 filed on Jan. 28, 2019, whichissued as U.S. Pat. No. 11,026,292, which is a National Stage Entry ofInternational Application No. PCT/JP2017/029618 filed on Aug. 18, 2017,which claims priority to European Patent Application No. 16185042.5filed on Aug. 19, 2016, the entire disclosures of which ae incorporatedherein their entirety by reference.

TECHNICAL FIELD

The present disclosure relates to a communication system. The disclosurehas particular but not exclusive relevance to wireless communicationsystems and devices thereof operating according to the 3rd GenerationPartnership Project (3GPP) standards or equivalents or derivativesthereof. The disclosure has particular although not exclusive relevanceto the so-called ‘Next Generation’ systems.

BACKGROUND ART

The disclosure includes a method for independent activation ordeactivation of user plane connection per Protocol Data Unit (PDU)session or network slice, where the session contexts in a User Equipment(UE) and in a network (e.g. a Session Management Function (SMF), and aUser Plane Function (UPF)) are already established. The solutionproposes a (Session Management (SM)) state machine for each establishedPDU session, where the state machine is maintained either in the SMF orin a Mobility Management Function (MMF) network function. The SM statemachines run independently of a Mobility Management (MM) state machine.

General

The following terminologies are used within this document and can beapplied to any generation of mobile networks like 2G (Global System ofMobile communications (GSM)), 3G (Universal Mobile TelecommunicationSystem (UMTS)), 4G (Long Term Evolution (LTE)/Evolved Packet Core(EPC)), 5G (New Radio (NR)/NextGen) or any other. For example, if the“UE” or a “serving node” is mentioned in the below description, it canbe any generation of the UE or the serving node.

The terms ‘serving node’, ‘Mobility Management Entity (MME)/ServingGeneral Packet Radio Service (GPRS) Support Node (SGSN)’, ‘MobileSwitching Centre (MSC)/SGSN/MME’, or Cellular Internet of Things (CIoT)Serving Gateway Node (C-SGN) is generally used through the variousembodiments of this document to describe a functional entity like theMSC, the SGSN, the MME, the C-SGN, or other possible control planefunctional entities in the mobile network which terminate a controlplane signalling (known as a Non Access Stratum (NAS) signalling)between a core network and a terminal. The serving node (MME/SGSN) canbe also a functional entity from future generation networks which isresponsible for mobility and session management.

The term Home Subscriber Server (HSS)/Home Location Register (HLR) meansa repository where the UE's subscription data is stored and can beeither the HSS or the HLR or a combined entity. Instead of the HSS alsothe term Next Generation User Data Management (UDM), Subscriber DatabaseManagement (SDM) or Authentication Authorization Accounting (AAA) couldbe used synonymously.

Functional entities or a network function used in this document asseparate entities could be also collocated together or even finerseparated in particular deployments or as described in the architecturefigures.

The terms ‘terminal’, ‘device’, ‘user terminal’, ‘User Equipment (UE)’,or ‘Mobile Terminal (MT)’ are used in an inter-exchangeable manner whereall of the terms express similarly an equipment used to send/receivedata and signalling from the network, a mobile network, or a radioaccess network.

The term “session” is used in the same meaning as a “PDU session”, a“Packet Data Network (PDN) connection”, an “Access Point Name (APN)connection”, or a “connection for a particular network slice”. Theexisting sessions are those sessions for which already UE context exists(is established) in the core network control plane and/or user plane andthe UE itself. The “existing sessions” has the same meaning as an“established PDU session” or an “established PDN connection”. Eachsession can be identified with a “session ID”, which can be similar toan “Evolved Packet System (EPS) bearer ID”, the “APN”, a “slice ID”, a“slice instance ID”, a “service ID” or any other temporary or apermanent identifier of the PDN connection, the PDU session or a serviceused by the UE.

The term “connection” is mostly used for user plane connection where akind of “path” is established to send uplink (UL) or downlink (DL) databetween the UE and a user plane Gateway (GW) terminating the PDUsession. Depending on the context, a connection can be either the wholeuser plane path for the PDU session; or only a connection over a giveninterface, e.g. connection over a radio interface, or connection overNG3 interface (between the UPF in a next generation core network (NG CN)and a (Radio) Access Network ((R)AN).

The following terminology for the procedures is used:

-   -   Session establishment: e.g. PDU session establishment where SM        context exists (is established) in the UE and in the NG CN        control plane and/or user plane.    -   Session release: deletion of the PDU session, which means the SM        context is deleted (released) in the UE and in the NG CN control        plane and/or user plane.    -   Session/connection activation: activating an UP connection path        for session, for which the SM context exist in the UE and in the        NG CN.    -   Session/connection deactivation: deactivating the UP connection        path without deleting the SM context in the UE and in the NG CN.        With other words just releasing the UP connection.

The mobility states of the UE are called De-Registered,Registered-Standby (“Standby” for simplicity) and Registered-Ready(“Ready” for simplicity). These states are also called MM states. Pleasenote that there is a difference between the mobility states (the MMstates) and session states (SM states).

The telecommunication industry started to work on new generation ofnetwork referred as 5th generation (5G) networks. Activities in multipleresearch and standardization organizations were initiated to develop the5G network which shall offer services to multiple vertical serviceproviders and serving high variety of terminals. Especially 3GPP inactivities were initiated in the RAN area under the term “New Radio”(NR) and in the core network (CN) under the term “NextGen” (NG). Pleasenote that those terms will most probably change before the 5G system isintroduced to the market. Therefore terms like NG CN (or NG AN) as usedin this document have the meaning of any 5G CN or AN technology.

3GPP studies the NG system architecture and corresponding issues andsolutions are captured in 3GPP TR 23.799 [see, NPL 1]. FIG. 1 describesthe NG architecture for simultaneous access to multiple PDN connections(called PDU sessions in the NG study), as agreed in [see, NPL 1] by thetime of writing. The upper part of FIG. 1 shows an example for NGcontrol plane (NG CP) including a subscriber database management (SDM)22, a Policy Control function (PCF) 24 and Core Control functions (CCFs)26. The NG CCF 26 includes among others mobility management function(MMF) and session management function (SMF). The user plane (UP)function(s) are shows as a Core User plane function (NG UPF) 28, asthere could be one or multiple UPFs per PDU session configured. Furtherinformation about the description of the interfaces and the networkfunctions can be found in TR 23.799 clause 7.3 [see, NPL 1].

One main feature of a 5G system is called network slicing. The 5G usecases demand very diverse and sometimes extreme requirements. Thecurrent architecture utilizes a relatively monolithic network andtransport framework. Thus, it is anticipated that the currentarchitecture is not flexible and scalable enough to efficiently supporta wider range of business needs. To meet such needs, the 5G NG systemcan be “sliced” in multiple network instances which are referred asnetwork slice instances (NSI). The network slices can be referred aslogically separated networks where the resources (processing, storageand networking resources) for different network slices are isolated. Anetwork operator uses a Network Slice Template/Blueprint to create aNSI. The NSI provides the network characteristics which are required bya Service Instance. One example of network architecture allowing a UE toconnect to multiple NSIs simultaneously is shown in FIG. 2 , asdescribed in [see, NPL 1].

FIG. 2 shows a first network slice type/category (e.g. for IoT services)and a second slice type (e.g. for broadband services). The secondnetwork slice type can have multiple NSIs for particular 3rd partycustomers. This figure shows that the (R)AN is shared and networkslicing is applied in the NG CN. However, in future also network slicingthe (R)AN is possible where the RAN resources are sliced/isolated,either in baseband processing or in frequency spectrum or both.

[NPL 1] also describes the Common Control Network Functions (CCNF) 32and Slice-specific Control Plane Network Functions (SCNF), as shown indetail in FIG. 3 . The CCNF 32 can include fundamental control planenetwork functions to support basic functions operation common among theNSIs, for example:

-   -   1. Subscriber Authenticator,    -   2. Mobility Management,    -   3. Network Slice Instance Selector (NSI Selector),    -   4. NAS Routing Function, etc.

In general, the NG system design should enable the transmission of anykind of data. It is assumed that the NG system supports the followingPDU session types:

-   -   IP type (e.g. IPv4 or IPv6 or both), or    -   non-IP session (any unstructured data) or    -   Ethernet type.

One further solution described in 23.799 in clause 6.4.3 is shown inFIG. 4 . The UE 34 may establish multiple PDU Sessions to the same datanetwork in order to satisfy different connectivity requirements ofdifferent applications (e.g. session continuity) that requireconnectivity to the same data network. In this solution, the MM and SMfunctions are separated. With this, one main concept is that multiple SMcontexts can be available per MM context. Also, different sessioncontinuity types per PDU session are possible.

CITATION LIST Non Patent Literature [NPL 1]

-   3GPP TR 23.799 v0.6.0, 2016-07, “Study on Architecture for Next    Generation System”

[NPL 2]

-   3GPP TS 23.401, v14.0.0, 2016-06, “General Packet Radio Service    (GPRS) enhancements for Evolved Universal Terrestrial Radio Access    Network (E-UTRAN) access”

SUMMARY OF INVENTION Technical Problem

The scenario considered in this document is that a UE is attached to thenetwork and can be associated with multiple UP-GWs (UPFs). The differentUPFs can be part of the (a) same PDU session, (b) part of different PDUsessions, or (3) part of different network slice instances (NSIs). Withother words, multiple NG3 connections (e.g. tunnels over NG3 interface)between the (R)AN and the UP-GWs can be available. If the UE hasestablished multiple PDU sessions, then multiple Session ManagementFunction (SMF) instances may exist per UE.

One assumption in this document is that a UE's “session” (or also called“PDN connection” or “PDU session” to a particular data network) can bein Idle (inactive) state or Active (connected) state. In this sense theterms “Idle session” or “Active session” are used. If a session is in“IDLE” state, then there is no NG3 connection/tunnel established betweenthe UPF and (R)AN. If a session is in “ACTIVE” state, then there is NG3connection/tunnel established between the UPF and (R)AN. It is furtherassumed that for an established UE's session a Session ManagementFunction (SMF) is instantiated/configured in the control plane andcorresponding one or more UPFs are instantiated/configured in the userplane. Further details about the IDLE and ACTIVE session state of theControl Plane Function (CPF) and the UPF can be found below.

Assuming that between the AN and the multiple UPFs there will be NG3tunnels setup for transmitting data packets, the problem occurs ofestablishment, modification and release of multiple NG3 tunnels eachtime when the UE transfers from Standby to Ready mobility state.

Compared with EPC where a single Serving GW is configured per UE, andthus a single S1-U tunnel is established and released duringStandby->Ready transition, in NG having multiple UPFs, multiple tunnelsover NG3 interface are established/released. Therefore the problem isthat the signalling for tunnel establishment is increased when a singleUPF (or PDU session) is in use, but multiple NG3 tunnels areestablished/released.

Further, if all existing sessions are in IDLE state and downlink dataarrives for a particular session, there should be a way to synchronizeSM state between the UE and the NG system. Thus, for a MT call, it iscurrently not possible for the UE to activate only a single Applicationwhich is associated to a session that triggers the MT call.

In addition, it is possible that a mobility management mechanismmaintains MM state always in Ready state in the NG core network (CN) aslong as the UE is attached/registered to the NG system. With this, theNG CN has only Registered and Deregistered mobility states of the UE.This MM mechanism is advantageous for paging of mainly stationarydevices or low-mobility devices for which the paging area is relativelynarrow. With this architecture, the NG CN knows the location of the UEand the NG3 tunnels are always active. This means that the Session stateis always “Active”. This document also targets to solve a potentialproblem in case such devices have another application which isconfigured to access with a different session at the same time. In thecase, the NG CN performs session management while the (R)AN performsmobility management. As a result, all NG3 connections/tunnels for allsessions are always established, i.e. all sessions are always in Activesession state. When the UE moves and changes (R)AN node, all tunnelsneeds to be updated, meaning that the CCNF and the SMFs needs to updateall UPFs with the new tunnel endpoint information. This would result inincreased signalling.

This disclosure seeks to solve or at least alleviate the above problemsby reducing the required signalling for NG3 tunnel establishmentallowing the activation of a particular session out of multiple existingsessions.

Solution to Problem

An example aspect of the present disclosure is a User Equipment (UE),including: a transmitter configured to transmit at least one ProtocolData Unit (PDU) session identifier (ID), each of which indicates a PDUsession that the UE needs to use in a Non Access Stratum (NAS) ServiceRequest message to a Mobility Management Function (MMF) via an accessnetwork (AN) node when the UE has user data to send.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 describes the NG architecture for access to multiple PDNconnections (called PDU sessions in the NG study);

FIG. 2 shows one example of network architecture allowing a UE toconnect to multiple NSIs;

FIG. 3 describes the CCNF and SCNF;

FIG. 4 shows one further solution described in 23.799 in clause 6.4.3;

FIG. 5 shows an example architecture showing multiple network slices orPDU sessions with corresponding multiple CPFs and UPFs;

FIG. 6 shows multiple session state machines (one per establishedsession) and a single mobility state machine;

FIG. 7 shows the existence of 2 sessions already established for a givenUE;

FIG. 8 shows that a paging procedure where the session ID for activationof a single PDU/PDN session is indicated to the UE during the RadioResource Control (RRC) connection establishment request;

FIG. 9 shows a possible solution 2.1 for the activation of additionalsession when another session is already in Active state;

FIG. 10 shows another alternative solution 2.2 where NAS SM signallingbetween the SMF2 and UE is used for the activation of the session 2towards UPF2;

FIG. 11 shows that the UE has two session contexts for session #1 andsession #2;

FIG. 12 describes a case where two sessions are Active and one of thembecomes Idle due to no user plane activity within predefined UEinactivity period determined by the (R)AN node;

FIG. 13 describes an alternative solution where the session deactivationprocedure is initiated by the UPF of the corresponding session;

FIG. 14 is a block diagram illustrating the main components of the UEshown in FIG. 1 ; and

FIG. 15 is a block diagram illustrating the main components of theMMF/SMF node shown in FIG. 1 .

DESCRIPTION OF EMBODIMENTS

In order to solve the above described problem, different solutions aredescribed in various example embodiments herewith.

Please note that the terms “Idle” session or “Active” session are usedfor the SM states, whereas Standby and Ready states are used for theUE's mobility states. Also the transition from Idle session state toActive session state can be called “session activation” whereas thetransition from Active session state to Idle session state can be called“session deactivation”. This is shown in FIG. 6 .

The terms “session activation” procedure or “session deactivation”procedure relates to the establishment or release of NG3connections/tunnels. These terms are different from “sessionestablishment” or “session release” procedures which relates to theestablishment of a new session including establishment of SM context inboth UE and NG CN or correspondingly deletion of existing session, i.e.deletion of the SM context in the UE and the NG CN.

For the purposes of this document the reference architecture from FIG. 1for a single established session (network slice or PDU session) isassumed. For multiple established sessions FIG. 5 is assumed asreference architecture where a UE has established 3 different sessionsA, B and C. The different sessions can belong to different networkslices or to the same network slice but having multiple PDU sessions. Inthe control plane there is a box denoting CCNF 32 which are shared amongnetwork slices or PDU sessions. These CCNFs can include mobilitymanagement Network Function (NF) (called MMF),Authentication/Authorization/Security NF, NAS signaling routing NF andothers. As it is shown in FIG. 5 , each PDU session or network slice canhave independent dedicated CPFs. The Dedicated CPFs can include thefollowing exemplary network functionality:

-   -   SMF: it is assumed in this document that this function is        responsible for the session management for a specific session        (network slice, or PDU sessions).    -   CPF of a GW (aka GW-C of the UPF), as the Control Plane (CP) of        the GW is known as S/PGW-CP function from the control/user plane        separation in EPC, called Control and User Plane Separation        (CUPS).    -   PCF: the complete or part of the PCF as described in FIG. 1 .        This means that some parts of the PCF can be a part of the CCNF        32 and other parts can be part of the Dedicated CPF.    -   Authentication, Authorization and Security functions related to        the specific Network slice of PDU session.

Please note that the UE 34 is shown in FIG. 5 by having 3 arrows towardsthe (R)AN node 30 which represents 3 radio connections corresponding tothe 3 sessions/slices A, B and C. However, this is just an example. TheUE 34 can have e.g. 3 user plane radio connections (each per session)and just a single control plane radio connection. Alternatively the UE34 can have 3 user plane radio connections and 3 control plane radioconnection (each per session).

For simplicity, within this document the term SMF is used to denote allDedicated CPFs as listed above for a PDU session or network slice. EachSMF has a signaling association with the CCNF 32 per the UE 34. For eachestablished session, the CCNF (e.g. MMF) 32 and the SMF know each otherand can send signaling at any time independent of the UE's mobility orsession state. Further, the CCNF 32 and the SMF have exchanged a UE IDor a subscriber ID (temporary or permanent) and use this ID in eachsignaling message exchange in order to point to the corresponding UE'scontext in the CCNF 32 or in the SMF.

In addition, a UPF (3GPP specified GW functionality e.g. to enforceQuality of Service (QoS) or traffic policies) per network slice or PDUsession is configured/instantiated. Each of the (NG3) connections A, Bor C can be managed independent, i.e. can be established, modified orreleased independent from the other connections. Please note that therecan be one or multiple UPFs. For example a UPF closer to the Edge can beused as mobility anchor and a UPF deeper in the CN can be used as IPanchor (hosting the UE's IP address). For simplicity, in this document asingle UPF is used. However, the SMF is able to configure multiple UPFsif multiple UPFs are needed and instantiated/configured for a givensession.

As exemplary shown in FIG. 5 , it is assumed that there are 3connections (e.g. tunnels over NG3) between (R)AN and UPFs: a singleconnection for slice/session A 36, slice/session B 38 and slice/sessionC 40. If tunneling over NG3 is used per UE 34 between (R)AN and UPFsA/B/C 36/38/40, then there will be 3 tunnels activated/modified/releasedeach time when the UE 34 transfers among Standby<->Ready mobility state.Even worse, if the tunneling over NG3 is per IP flow or per bearer theneven more tunnels need to be activated/modified/released for eachStandby and Ready mobility state transition.

FIG. 5 shows for session C that the dedicated CPFs can include the SMFand the PCF. It is noted that the existence of PCF in the dedicated CPFmay be based on the particular use case, e.g. for some network slicesthe PCF can be instantiated/configured per slice, whereas for othernetwork slices the PCF can be instantiated/configured as common CPNF.

In this document it is proposed that in case of multipleexisting/established PDU sessions (or connectivity to multiplenetwork-slices simultaneously) the system architecture allows toactivate/deactivate a single session, which means 1) activating thesession state in the corresponding CPF, e.g. SMF; and 2) to activate asingle UP session by establishing a corresponding connection/tunnelbetween the (R)AN node 30 and the UPF. Other UP sessions (for other PDUsessions or other network slices) are not activated (i.e. in Idle state)if there is no data sent in uplink or downlink (UL or DL).

As depicted in FIG. 6 , there are independent session state machines perexisting session (i.e. per network slice, or PDU session). This is shownas Session A state machine and Session B state machine. This sessionstate machines are applicable both in the UE 34 and in the NG CN. Duringthe establishment of a UE session, a SMF entity is selected andconfigured by the CCNF (MMF). The SMF entity starts maintaining UE'scontext related to this session. For example, the UE's session contextin the SMF can contain among others the following parameters:

-   -   UE temporary or permanent ID, corresponding session ID;    -   session type (e.g. IPv4/Ipv6, non-IP, Ethernet);    -   session continuity and/or service continuity mode(s) (e.g.        Session and Service Continuity (SSC) mode 1/2/3);    -   QoS parameters (e.g. non-Guaranteed Bit Rate (non-GBR), GBR        parameters, maximum session bit rate);    -   policy parameters;    -   needed session subscription parameters;    -   session state machine, etc.

With other words, independent of the state (Active or Idle) of thesession state machine in the SMF, the SMF maintains UE's session contextlike the parameters listed above.

In addition, in case that the UE 34 is a permanent Ready mobility statefrom NG CN perspective, this may result in permanently activatedconnections/tunnels over NG3 interface and correspondingly resulting insessions which are in permanent Active session state in the NG CN. Thenthe session (SM) state machines can be managed either in the (R)AN or inthe NG CN. The transition from Idle to Active session state happens forexample 1) if data for transmission in the UL or the DL is available or2) if a scheduled session activation is configured in the SMF. In Activesession state the SMF knows the current location of the UE in terms of(R)AN node UP details for data forwarding. Correspondingly the UPF hasestablished connection with the (R)AN node 30 over NG3 interface andpolicy and QoS parameters has been enforced in the UPF for the givensession. If there is no data in the UL or the DL or there is no need tokeep the user plane connection for a particular session, the (R)AN node30 or the UPF can trigger transition to Idle session state. Please notethat the UP connection deactivation is different from session release,as in connection deactivation the UE's context is still kept in the NGCN (e.g. SMF). In Idle session state the UPF does not have anestablished connection over NG3 interface and the SMF does not know(R)AN node UP details and exact MM mobility state (i.e. RegisteredStandby or Ready).

When the SMF for a given session (e.g. SMF-A) is in Idle state, in CPthe SMF doesn't know the (R)AN node UP details, e.g. IP address, tunnelidentifier, transport port ID, or other parameters. The SMF does haveUE's context about this session, for example including QoS parameter,policy parameters (e.g. Charging policies or Application Detectionpolicies), or needed session subscription parameters, etc. In the UP,the UPF does not have connection (e.g. no tunnel established) towardsthe (R)AN node 30.

On the other hand, if an SM instance in Active state, in CP the SMF(e.g. SMF-A) knows the (R)AN node details like IP address, tunnelidentifier, transport port ID, or other parameters. In the UP, the UPFhas a connection/tunnel established to the (R)AN node 30.

This document focuses on the procedures for activation and deactivationof sessions (i.e. activation/deactivation of UP connections), which isdifferent from the procedures for establishment of a new session orrelease of an existing session. For example the establishment of a newsession means the establishment of UE's SM session context in the SMF,the session context in the UE 34 itself and the corresponding NAS SMmessage exchange between the UE 34 and the SMF. It is assumed that foreach established session, the SMF and the MMF 32 maintain a signallingassociation for exchanging session-related signalling.

In another example, the release of an existing session means thedeletion of the SM context in the SMF, in the UPF and in the UE. Forexample if the UE 34 is detached from the network, i.e. the MM state isDeregistered, then the MMF 32 triggers a session release procedure,which is also not in the scope of this this document.

This document proposes that the CCNF (e.g. MMF) 32 maintains UE'scontext having knowledge about the session (SM) state in the SMF(s).With other words, the MMF 32 knows the session state (Idle or Active) ofall configured SMF(s) for the established sessions. In addition to themobility (MM) context, the MMF 32 maintains also information for allestablished sessions. For example the MMF 32 needs to know if a sessionA is activated, i.e. the SMF-A is in Active state, so that the MMF 32 isable to update the SMF with the new (R)AN node details (e.g. IP address,tunnel identifier, transport port ID, or other parameters) each timewhen (R)AN node changes. On the other hand, if a session A isdeactivated, i.e. the SMF-A is in Idle state, then the MMF 32 does notneed to update the SMF when (R)AN node changes. In one alternative, thesession states as shown in FIG. 6 can be also maintained in the MMF 32only, or in both the MMF 32 and the SMF.

For this purpose, the signalling exchange between the SMF and the MMF 32may be based on various alternatives:

-   -   Direct/explicit signalling between the SMF and the MMF 32 (in        both directions) is used to exchange information about the        current session state. The SMF can inform the MMF 32 about the        session's state each time when the session state changes. If the        MMF 32 knows that a particular session is in Active state, the        MMF 32 informs the SMF corresponding to this session about (R)AN        node changes, other Radio Access Technology (RAT) events (e.g.        RAT changes) and other possible mobility events. Further, during        Active session state the SMF may inform the MMF 32 about UPF        changes, e.g. due to load balancing or other events the UPF for        this session can change.    -   Alternatively, there may be no explicit signalling between the        SMF and the MMF 32 needed to inform the session state change, as        the MMF 32 may derive the session state based on the NAS        signalling between the UE 34 and the SMF.

In general, the SMF does not need to maintain current MM stateinformation. For example, if a particular session is in Idle state, theSMF does not need to know whether the UE 34 changes from Ready toStandby mobility state due to transmission of UL or DL data for othersessions. In contrast, if a session is in Active state, thecorresponding SMF needs to know about (R)AN node details (UP detailslike IP address and/or tunnel endpoint IDs), other RAT events (RATchanges) and change from Ready to Standby MM state. The latter event ofchange from Ready to Standby MM state would result in the SMF to triggerthe UPF to deactivate the NG3 connection/tunnel.

Assuming that the session states (Idle, Active) are maintained in the UE34 and the SMF, then direct signalling exchange between the UE 34 andthe SMF is advantageous. Such signalling exchange is based on NAS SMsignalling enhanced with additional parameters like session ID orindication for UP connection activation or deactivation.

Several procedures are described below to cover the activation anddeactivation of a session considering the various trigger sources.

Solution 1: Session Activation when No Another Active Session Exists(e.g. UE is in Standby MM State)

The solution described herewith is related to the scenario wheremultiple sessions have been established (e.g. towards different networkslices or different PDU sessions) and the UE 34 is in Standby mobilitystate. This means that all session are in Idle session state. If adownlink data arrives for a given session, then the solution proposedherewith allows activating only this particular session or in additionanother session(s) whereas other existing sessions continue to be Idlestate.

Solution 1.1: Indication of Session ID to UE During the Paging Procedure

In particular, FIG. 7 shows the existence of 2 sessions alreadyestablished for a given UE 34. This means that the UE 34 has IPconfiguration for each session and can send and receive data over eachsession. As the UE 34 is in Standby mobility state (shown as the CCNF 32in Standby state), the corresponding session #1 state (represented bythe SMF1 42 in the CP) and session #2 state (represented by the SMF2 44in the CP) are in Idle too. In the UP, the UPF1 46 and the UPF2 48 havea UE-related context (e.g. to enforce policies for the configured UE'sIP addresses and association with the corresponding CPF like the SMF),but there is no connection/tunnel to any (R)AN node 30 to transmitpackets.

The steps from FIG. 7 are described in detail as follows:

-   -   Step (1) Downlink data arrives at the UPF2 48. As the session #2        is in Idle state, the UPF2 48 does not have an established        connection/tunnel towards any (R)AN node 30. It is assumed that        there is a NG4 session established for the given the UE 34        between the CPF and the UPF. Thus, the UPF2 48 requests the CPF        corresponding to this session (e.g. the SMF2 44) to initiate        session activation.    -   Step (2) The UPF2 48 initiates a procedure for activating the        user plane connection (e.g. NG3 tunnel) towards the (R)AN. The        UPF2 48 sends an Activate session request to the SMF2 44. This        message can be also called a Create session request, a NG3/UP        session request, or any other similar to corresponding Sx        interface related message specified in TS 23.214. The Activate        session request can include one or several of the following        informational elements: a UE temporary or a permanent        identifier, a session identifier, a DL packet buffering        indication, and other parameters.    -   Step (3) The SMF2 44 receives the request from the UPF2 48 and        validates the message and determines the corresponding UE's        context and session(s) which needs to be activated. The SMF2 44        sends an Activate session request towards the CCNF (e.g. MMF)        32. Similar to step (2), this message can be called differently        e.g. the Create session request (or the NG3/UP session request)        as long as the message serves the purpose of        activating/establishing a UP connection between the (R)AN node        30 and the UPF. This message can also be called a Session        activation request or any other expressing the activation of an        existing PDN (PDU/bearer) context. The request from the SMF2 44        can contain UE ID(s), a session ID, a UPF ID (needed for NG3        tunnel establishment, e.g. an IP address, a tunnelling endpoint        ID and/or a transport layer port ID), required QoS indication,        optionally security keys and other parameters. Depending on the        power saving mode, if the Activate session request may contain a        user packet to be buffered. The SMF2 44 determines whether        another UPF served by the same SMF2 44 has already an active        session. If this is not the case, the SMF2 44 requests the        associated CCNF (e.g. MMF) 32 to perform the session activation        procedure toward the (R)AN, if needed.    -   The security keys can be used in case that there is different        security required for the particular UP session and the keys are        stored in the SMF.    -   Step (4) The CCNF (e.g. MMF) 32 determines whether the UE 34 is        in Standby or Ready mobility state. In this example, because the        UE 34 is Standby state, e.g. not know (R)AN location, the CCNF        32 initiates a paging procedure.    -   Step (5) The CCNF 32 sends a paging request towards the possible        (R)AN nodes 30 where the UE 34 camps. In this paging message,        the CCNF 32 includes single or multiple session ID(s). The        session ID(s) can be any of an APN, a slice ID, a slice instance        ID or a service ID. The CCNF 32 includes multiple session ID(s)        based on subscriber data in the CCNF 32 that has been obtained        from the HSS. Additional session ID(s) may be related to the        original session ID that corresponds to the SMF2 44 in this flow        or totally independent from the original session ID.    -   Step (6) The (R)AN node 30 performs the paging procedure over        the radio interface including the received session ID(s) in step        (5).    -   Step (7) After the UE 34 receives a paging message, the UE 34        performs radio connection establishment with the (R)AN node 30        and sends a NAS Service Request message to the CCNF 32 over NG1.        Both the radio connection establishment message and the NAS        Service Request message may include single or multiple session        ID(s). The UE radio layer(s) indicates via internal Application        Programing Interfaces (APIs) to the service, application or        existing PDN/APN/PDU/bearer context that corresponds to this        explicit session to be activated. Such internal cross-layer        exchange in the UE 34 can be performed either at step (7) or        after step (9).    -   The UE 34 can include the session ID(s) in the NAS Service        request message in order to indicate to the MMF (as part of the        CCNF 32) that the session ID(s) has been successfully processed        in the UE 34. Please note that the CCNF 32 may have a front-end        functionality for NAS signalling, so that the NAS Service        Request message after reaching the front-end can be internally        forwarded to the correct MMF for further processing. If the        session ID(s) is/are missing in the Service request message,        this may be an implicit indication that the UE 34 couldn't        process the session ID(s) from the paging message.    -   Step (8) The CCNF (e.g. MMF) 32 determines (correlates) that the        NAS Service Request message is as result to the Paging        procedure. The CCNF 32 determines that only a session requested        by the SMF2 44 needs to be activated. The CCNF 32 generates the        corresponding UE context setup request message and sends it to        the (R)AN node 30. The UE context setup request message        contains, in addition to other UE parameters like required QoS        indication and security parameters, also a session ID parameter.        When multiple sessions need to be activated, this step (8) can        be either executed session by session or one procedure activates        all requested sessions at once.    -   Step (9) The (R)AN node 30 performs radio connection        reconfiguration shown as Radio Resource Control (RRC) connection        reconfiguration in the figure. During this procedure, the (R)AN        node 30 indicates the session ID parameter to the UE 34.    -   Based on the received session ID, the UE 34 can activate the        corresponding service, application or existing        PDN/APN/PDU/bearer context. The UE 34 does not activate all        existing PDN/APN/PDU/bearer contexts. The UE 34 updates SM state        in the UE 34 that corresponds to the session ID(s) received by        step (6).    -   Step (10) The (R)AN node 30 responds to the request in step (8)        about the establishment of the radio connection. The (R)AN node        30 for example sends a UE context setup response message. The        response can be positive or negative. The UE context setup        response message includes the UP identifier of the (R)AN node 30        (IP address and tunnelling endpoint ID and/or transport layer        port ID) shown as (R)AN UPF ID in the figure. In case the CCNF        32 decided to add additional session ID(s) in step (5), then the        CCNF 32 initiates to activate session(s) towards associated UPF        to each additional sessions. The CCNF 32 informs all associated        UPF(s) via associated SMF(s) of the UP identifier of the (R)AN        node 30 (an IP address, a tunnelling endpoint ID and/or a        transport layer port ID) shown as (R)AN UPF ID in the figure.    -   Step (11) The CCNF 32 responds to the SMF2 44 corresponding to        the request in step (3). For example the CCNF 32 sends an        Activate session response message which can contain an        indication about the successful or unsuccessful activation of        the session corresponding to the session ID. This message        includes in addition to other UE parameters like required a QoS        indication (or modified QoS parameters) and security parameters,        also a session ID parameter.    -   The SMF2 44 derives the policy and QoS parameters to be enforced        in the UPF2 48.    -   The SMF2 44 transfers from Idle session state to Active session        state.    -   Step (12) The SMF2 44 responds to the step (2) procedure. The        SMF2 44 establishes or modifies the needed UE context in the        UPF2 48 by sending an Activate session response message. This        message can include parameters for policy enforcement (like a        traffic QoS indication, a traffic gating behaviour, a session        maximum bitrate), the (R)AN UPF ID (including the (R)AN node IP        address, the tunnelling endpoint ID and/or the transport layer        port ID), charging related configuration (e.g. for Charging Data        Record (CDR) generation and/or online/offline charging session        establishment), optionally security parameters, among others.    -   Please note that the security parameters are needed in case of        security termination at the CN UPF node like the UPF2 48. In        case where the security is terminated at the (R)AN node 30,        security parameters are not needed at this step.    -   Step (13) to step (15): If the UPF information for NG3        connection/tunnel establishment hasn't been exchanged during        step (3), then the UPF2 48 may optionally perform the Update        session procedure towards the SMF2 44 in order to update the UP        connection information called a UPF ID (e.g. an IP address, a        tunnelling endpoint ID and/or a transport layer port ID).        Alternatively the SMF2 44 may have such a NG3-related UP        information itself, so that SMF2 44 can initiate the Update        session procedure (by sending a session update request message        including the UPF ID) towards the CCNF (e.g. MMF) 32. Finally        the CCNF (e.g. MMF) 32 updates the (R)AN node 30 with the UPF        ID.

Solution 1.2: Indication of Session ID to UE During the Service Requestor Corresponding RRC Establishment Procedure

FIG. 8 shows an alternative solution where the paging procedure isenhanced to include the session ID parameter in the paging requestmessage.

FIG. 8 shows that a paging procedure where the Paging message does notinclude a session ID, but instead the session ID for activation of asingle PDU/PDN session is indicated to the UE 34 during the RRCconnection establishment procedure. Only steps (5)-(9) are described indetails below, as the rest of the steps are similar to FIG. 7 .

-   -   Step (5) The CCNF 32 sends a paging request towards the possible        (R)AN nodes 30 where the UE 34 camps. The paging request message        does not include a session ID parameter to indicate to the UE 34        which session should be activated.    -   Step (6) The (R)AN node 30 performs paging over the radio        interface. This message does not include the session ID as per        step (5).    -   Step (7) After the UE 34 receives a paging message, the UE 34        performs radio connection establishment with the (R)AN node 30        and sends a NAS Service Request message to the CCNF 32 over NG1.    -   Step (8) The CCNF 32 determines (correlates) that the NAS        Service Request message is as result to the Paging procedure.        The CCNF 32 determines that only a session requested by the SMF2        44 in step (3) needs to be activated. The CCNF (e.g. MMF) 32        changes the UE mobility state from Standby state to Ready state.    -   The CCNF 32 generates the corresponding UE context setup request        message and sends it to the (R)AN node 30. The UE context setup        request message contains, in addition to other UE parameters        like QoS and security parameters, also a session ID parameter.        When multiple sessions need to be activated, this step (8) can        be either executed session by session or one procedure activates        all requested sessions at once (e.g. by including a list of all        session IDs and corresponding parameters).    -   Step (9) The (R)AN node 30 performs radio connection        reconfiguration shown as RRC connection reconfiguration in the        figure. During this procedure, the (R)AN node 30 indicates to        the UE the session ID parameter for the session to be activated.    -   Based on the received session ID, the UE 34 can activate the        corresponding service, application or existing        PDN/APN/PDU/bearer context. The UE 34 does not activate all        existing PDN/APN/PDU/bearer contexts, but only the indicated        ones. The UE 34 updates its session/SM state(s) that corresponds        to the session ID(s) received by step (9).

Please note that steps (13) to (15) in FIG. 7 can be performed insolution 1.2 as well (although not shown in FIG. 8 ).

The choice between the solution alternatives shown in FIG. 7 or in FIG.8 can be done in the CCNF (e.g. MMF) 32 based on the capabilities of the(R)AN nodes 30 or based on the capabilities of the UE 34. The UEcapabilities regarding supported paging feature(s) can be exchangedduring the Attach procedure or other mobility procedure via NAS MMsignaling. The (R)AN node capabilities can be exchanged during theinterface setup between the (R)AN node 30 and the CCNF 32 (e.g. NG2interface or S1-MME setup exchange).

Solution 2: Activation of Session when Other Active Session(s) Exist(e.g. UE is in MM Ready State)

While the scenario solved in solution 1 has the assumption that thereare no other session in Active state (e.g. the UE 34 is in Standbymobility state), the assumption for solution 2 is that the UE 34 is inReady mobility state during DL data is arriving for a session which isin Idle state. In particular, considering FIG. 9 , it is assumed thatthe UE 34 has an Active session context for Session #1 terminated at theUPF1 46.

The unique problem is that the UE 34 already has existing PDU session(e.g. SM) contexts in Idle session state and the radio connection to beestablished shall be linked to this single PDU context out of multipleexisting PDU session contexts. It is proposed that such a linkagebetween a new data radio connection/bearer and existing session contextin the UE 34 is performed by using the session ID.

FIG. 9 shows a possible solution 2.1 for the activation of an additionalsession when another session is already in Active state. This solution2.1 alternative is based on a new UE context modification requestprocedure.

The steps in FIG. 9 are described as follows:

-   -   Step (1) Similar to step (1) in FIG. 7 .    -   Step (2) Similar to step (2) in FIG. 7 .    -   Step (3) Similar to step (3) in FIG. 7 .    -   Step (4) The CCNF (e.g. MMF) 32 determines that the UE 34 is in        Ready mobility state. The CCNF 32 initiates a UE context        modification procedure used to update the UE's context in the        (R)AN node 30 with the new session parameters.    -   Step (5) The CCNF 32 sends for example a UE context modification        request message. This message includes, in addition to other UE        parameters like QoS and security parameters, also a session ID        parameter received during step (3).    -   Step (6) The (R)AN node 30 performs a radio connection        reconfiguration procedure shown as RRC connection        reconfiguration in the figure. During this procedure, the (R)AN        node 30 indicates the session ID parameter to the UE 34. The        (R)AN node 30 can setup a new data radio bearer or can re-use an        existing data radio bearer. The (R)AN node 30 takes this        decision based on the QoS parameters related to the new session        and the already established data radio bearer.    -   Based on the received session ID, the UE 34 activates the        corresponding service, application or existing        PDN/APN/PDU/bearer context. The UE 34 does not activate any        additional existing PDN/APN/PDU/bearer contexts. With other        words the UE 34 makes a linkage between the new established data        radio bearer and the existing PDN/APN/PDU/bearer context based        on the session ID parameter.    -   Step (7) The (R)AN node 30 responds to the CCNF 32. For example        the (R)AN node 30 can send a UE context modification response        message referring to the request in step (5).    -   Step (8) Similar to step (11) in FIG. 7 . The SMF2 44 transfers        from Idle session state to Active session state.    -   Step (9) Similar to step (12) in FIG. 7 .

Please note that steps (13) to (15) in FIG. 7 can be performed insolution 2.1 as well (although not shown in FIG. 9 ).

FIG. 10 shows another alternative solution 2.2 where NAS SM signallingbetween the SMF2 44 and the UE 34 is used for the activation of thesession 2 towards the UPF2 48.

The steps in FIG. 10 are described as follows:

-   -   Step (1) Similar to step (1) in FIG. 7 .    -   Step (2) Similar to step (2) in FIG. 7 .    -   Step (3) The SMF2 44 generates a NAS SM message (exemplary        called a NAS SM Activation request) and sends it toward the UE        34. This NAS message includes a UE ID, a session ID, cause        values (e.g. activation, modify, deleted) and other parameters.        For the transmission of the NAS SM Activation request message to        the UE 34, there can be multiple options:        -   (A) sent via the MMF 32 by encapsulating the NAS SM            Activation request message into an Activate session request            message from the SMF2 44 to the MMF 32; or        -   (B) sent in a separate transmission/transport message            between the SMF2 44 and the MMF 32; or        -   (C) sent to a NAS front-end functionality within the CCNF            32, which forwards the message to the UE 34, i.e. the NAS SM            message does not traverse through the MMF 32. In this latter            case (C), the SMF2 44 needs to send another message to the            MMF 32, e.g. an Activate session request message, in order            to inform the MMF 32 about the need to activate the session            #2 (UP connection).    -   Step (4) The CCNF (e.g. MMF) 32 determines that the UE 34 is in        Ready mobility state and the session corresponding to “session        ID” parameter needs to be activated. In addition the CCNF 32        needs to route and encapsulate the NAS SM Activation request        towards the (R)AN node 30. The CCNF 32 can initiate a UE context        modification procedure used to update the UE's context in the        (R)AN node 30 with the new session parameters.    -   Step (5) The CCNF 32 sends for example a UE context modification        request message. This message includes, in addition to other UE        parameters like QoS parameters and security parameters, also a        session ID parameter received during step (3). The CCNF 32        transmits the NAS SM Activation request towards the (R)AN node        30 either within the UE context modification request message or        in another NG2 message used for transport of NAS signalling,        e.g. a NG DL transport message (not shown in FIG. 10 ).    -   Step (6) This step may contain 2 independent message        transmissions: step (6.a) represents an example of a Radio        Resource Control (RRC) DL Direct transfer message to carry the        NAS SM Activation request towards the UE 34. In step (6.b) the        (R)AN node 30 performs a radio connection reconfiguration        procedure shown as RRC connection reconfiguration similar to        step (6) in FIG. 9 .    -   Based on the received NAS SM Activation request, the UE 34        activates the corresponding service, application or existing        PDN/APN/PDU/bearer context. The UE 34 does not activate any        additional existing PDN/APN/PDU/bearer contexts. With other        words the UE 34 makes a linkage between the new established data        radio bearer and the existing PDN/APN/PDU/bearer context based        on the session ID parameter.    -   Step (7) The (R)AN node 30 responds to the CCNF 32. For example        the (R)AN node 30 can send a UE context modification response        message referring to the request in step (5).    -   Step (8) The UE 34 generates a NAS SM Activation response        message and sends it towards the SMF2 44. This NAS SM message        can be transmitted over a RRC UL Direct transfer message.    -   Step (9) The (R)AN node 30 receives the RRC UL Direct transfer        message, extracts the NAS SM Activation response message and        forwards it to the CCNF 32.    -   Step (10) Similar to step (11) in FIG. 7 . In addition the CCNF        (MMF) 32 transfers the NAS SM Activation response message to the        SMF2 44 either as part of the Activate session response message        or as part of a new transfer message between the MMF 32 and the        SMF2 44.

The SMF2 44 transfers from Idle session state to Active session state.

-   -   Step (11) Similar to step (12) in FIG. 7 .

Please note that steps (13) to (15) in FIG. 7 can be performed insolution 2.2 as well (although not shown in FIG. 10 ).

Alternatively, in solution 2.2 the SMF2 44 may trigger the sessionactivation by itself, i.e. without trigger from the UPF2 48. This ispossible in case there is a scheduled session activation in the SMF2 44.Such scheduling can be based on a timer or clock running in the SMF2 44as part of the processing of the UE's SM context in the SMF2 44. TheSMF2 44, based on such a clock for scheduling, can trigger theestablishment of UP connection by performing step (3) towards the MMF32, and perform a new step to insert UP-related information towards theUPF2 48 (basically step (11) above).

In summary, solution 2.1 or solution 2.2 allows to activate anindividual session (UP connection) while other UP connection exists.

Solution 3: Activation of Session Triggered by UL Data (in the UE)

While solution 1 and solution 2 (with their variants) explain theactivation of the UP connection triggered by DL data (in the UPF), thissolution describes the activation of a single UP connection triggered byUL data (in the UE).

FIG. 11 shows that the UE 34 has two session contexts for session #1 andsession #2. There are two different cases described. In case (A) the UE34 is in Standby mobility (MM) state, and thus, all session states arein Idle state. In case (B) the UE 34 is in Ready mobility (MM) state andsession #1 is in use, i.e. there are the radio connection and the NG3connection established.

The steps in FIG. 11 are described in details as follows:

-   -   Step (1) UL data from particular App/service has to be sent by        the UE 34, e.g. over session #2. As session #2 is in Idle state,        the UE 34 needs to activate the UP connection in order to        transmit the data.    -   Step (2) If the UE 34 is in MM Standby state, the UE 34 first        needs to activate the radio CP connection (RRC) and the NAS        connection by initiating a service request procedure. For this        purpose the UE 34 first establishes RRC connection.    -   Step (3) If the UE 34 is in MM Standby state, the UE 34        transmits a NAS Service Request message to activate the NAS        signalling connection. The NAS Service Request message can        contain among others also a “session ID” parameter. If the NAS        signalling connection is terminated at a NAS front-end        functionality, the NAS front-end functionality forwards the NAS        Service Request message to the MMF 32.    -   Step (4) The CCNF (e.g. MMF) 32 verifies and processes the NAS        Service Request message. Based on the “session ID” parameter,        the MMF 32 determines which session needs to be activated. In        this particular example the MMF 32 determines that session #2        needs to be activated. The MMF 32 initiates towards the SMF2 44        a procedure for activation of the UP connection. The MMF 32        sends an Activate session request message (or a similar message        as already described in step (3) in FIG. 7 ). This message        contains among other parameters, a UE ID, a session ID, a cause        value (e.g. activation, modification, delete), etc.    -   Step (5) If the UE 34 is in MM Ready state, the UE 34 already        has a signalling connection towards the NG CN. The UE 34 can        initiate a NAS connection activation procedure. For this        purpose, the UE 34 sends a NAS SM session activation request        message towards the corresponding SMF, in this particular        example SMF2 44. The NAS SM session activation request message        can be either forwarded via a common NAS front-end functionality        towards the SMF2 44, or forwarded via the MMF 32 towards the        SMF2 44. The NAS SM session activation request message contains        among others also the parameters of the UE ID, the session ID,        and/or the cause value (e.g. activation, modification, delete),        etc.    -   Step (6) The SMF2 44 receives the messages either in step (4) or        in step (5) and processes it. The SMF2 44 determines the QoS        parameters and other policy parameters to be enforced in the        UPF2 48. The SMF2 44 initiates a session activation procedure        towards the UPF2 48. The SMF2 44 sends an Activate session        request message to the UPF2 48 including among others QoS and        policy parameters and optionally NG3-specific parameters (e.g.        tunnelling information like an IP address to be used by the UPF2        48 and/or a General packet radio service Tunneling Protocol        (GTP) Tunnel Endpoint Identifier (TEID)).    -   Step (7) The UPF2 48 receives the Activate session request        message and processes it. The UPF2 48 sends an Activate session        response message to the SMF2 44 and if needed, indicates an        activation result cause value and NG3-specific parameters (e.g.        tunnelling information like the IP address to be used by the        UPF2 48 and/or the GTP TEID).    -   Step (8) If needed, the SMF2 44 may send a NAS SM message, e.g.        a NAS SM session activation response message, to the UE 34. Such        a NAS SM message can include various session management        parameters, e.g. for session QoS or policy modification.    -   Step (9) Depending on the previous options (A) or (B), the SMF2        44 can have different behaviour. In one option, the SMF2 44        replies to step (4). In another option, the SMF2 44 may initiate        a session activation procedure towards the CCNF (e.g. MMF) 32        and the (R)AN node 30. For example the SMF2 44 can send an        Activate session request/response message towards the CCNF (e.g.        MMF) 32 including the session ID, and UPF NG3-related        information (e.g. tunnelling information like the IP address of        the UPF2 48 and/or the GTP TEID)    -   Step (10) Depending on the MM state in which the UE 34 was in        the beginning, i.e. depending on options (A) and (B), the CCNF        (e.g. MMF) 32 initiates different procedures:        -   in case of option (A), i.e. the UE 34 was in MM Standby            state, the CCNF 32 initiates a UE context setup procedure            towards the (R)AN node 30 by sending a UE context setup            request message. This message may include among others, the            session ID, QoS, security and other parameters needed for            the establishment of the radio connection, e.g. UPF            NG3-related information (e.g. tunnelling information like            the IP address of the UPF2 48 and/or the GTP TEID).        -   in case of option (B), i.e. the UE 34 was in MM Ready state,            the CCNF (MMF) 32 initiates a UE context modification            procedure towards the (R)AN node 30. The CCNF (MMF) 32 sends            a UE context modification request message to the (R)AN node            30 to modify the radio connection and to assist the            establishment of NG3 connection towards the UPF2 48. The UE            context modification request message can contain among            others, the session ID, the QoS, security and other            parameters needed for the establishment of the radio            connection, e.g. UPF NG3-related information (e.g.            tunnelling information like the IP address of the UPF2 48            and/or the GTP TEID).    -   Step (11) The (R)AN node 30 performs RRC connection        reconfiguration to establish the data radio connection for        session #2. For this purpose the (R)AN node 30 performs a RRC        connection reconfiguration procedure.    -   Step (12) The (R)AN node 30 replies to step (10). The (R)AN node        30 sends a UE context setup response message including the (R)AN        node UP NG3-related information (e.g. tunnelling information        like IP address of the UPF2 48 and/or GTP TEID), to the CCNF 32.

Please note that several options are possible:

-   -   option 1: The (R)AN node 30 sends the UE context setup response        message to the MMF 32.    -   option 2: The (R)AN node 30 sends the UE context setup response        message to a NG2 front-end functionality within the CCNF 32. The        front-end functionality can forward the content of the UE        context setup response message to the MMF 32 and/or the SMF2 44.    -   option 3: The (R)AN node 30 sends the UE context setup response        message to the SMF2 44.    -   option 4: The (R)AN node 30 sends 2 different messages to the        MMF 32 and the SMF2 44. The message to the MMF 32 confirms the        successful establishment of the new data radio connection,        whereas the message to the SMF2 44 carries in addition (R)AN        node UP NG3-related information (e.g. tunnelling information        like the IP address of the UPF2 48 and/or the GTP TEID)    -   Step (13) In case of option 1 from step (12) above, the MMF 32        initiates a session update procedure towards the SMF2 44 in        order to update the (R)AN node UP NG3-related information (e.g.        tunnelling information like the IP address of the UPF2 48 and/or        the GTP TEID).    -   Step (14) The SMF2 44 initiates a session update procedure        towards the UPF2 48. The SMF2 44 sends a Update session request        message to the UPF2 48 including the (R)AN node UP NG3-related        information (e.g. tunnelling information like the IP address of        the UPF2 48 and/or the GTP TEID).

Solution 4: Deactivation of Single Session while Other Session(s)Continue to be in Active State Solution 4.1: Session DeactivationInitiated by the RAN Node

In order to manage sessions independently (i.e. per session basis), itshall be possible to release the UP connection of a single session(called “session deactivation” in this document). With other words asingle radio connection and a NG3 connection can be released, whilekeeping the remaining existing session's connection active.

In one alternative solution it is assumed that (R)AN node 30 triggersthe deactivation of a session. Usually the (R)AN node 30 manages radiorelated parameters, such as a UE inactivity timer, an activediscontinuous reception (DRX) cycle, an idle DRX cycle, etc. Thissolution proposes that such radio parameters are maintained per session.With this, if multiple radio connections for multiple sessions areactivated, the (R)AN node 30 maintains a so called “session inactivitytimer” per activated session. This “session inactivity timer” isdifferent from the UE inactivity timer, as the “session inactivitytimer” applies to a single session (a radio connection like a data radiobearer (DRB) in LTE).

FIG. 12 describes a case where two sessions are Active and one of thembecomes Idle due to no user plane activity within a predefined UEinactivity period determined by the (R)AN node 30. As starting point,the thick arrows show the data flow in UL and DL between the UE 34 and,the UPF1 46 and the UPF2 48 correspondingly.

The steps in FIG. 12 are described as follows:

-   -   Step (1) The UE Inactivity timer in the (R)AN node 30 expires        for the session #1. It means that the (R)AN node 30 has        determined that no data has been transmitted in the UL or the DL        for a given period of time denoted as the “inactivity timer” for        session #1.    -   Step (2) The (R)AN node 30 has 2 options depending on the number        of remaining active sessions (or radio connections).    -   Option (2.a) If this is not the last active session, (R)AN node        30 initiates a UE connection release procedure towards the CCNF        32. The (R)AN node 30 sends a UE connection release request        message to the CCNF 32. This message includes a UE        temporary/permanent ID, an indication which session has to be        deactivated (e.g. session #1), a cause value and other        parameters.    -   Option (2.b) If this is the last active session (e.g. existing        radio connection), the (R)AN node 30 initiates a UE context        release procedure. This would enforce change of the        mobility (MM) state from Ready to Standby. This message includes        a UE temporary/permanent ID, an indication about a cause value        and other parameters.    -   Step (3) The CCNF 32 processes the UE connection release request        message and determines which SMF needs to be contacted. The CCNF        32 sends a NG3 release request to the SMF1 42. Please note that        this message can be also called a Deactivate session request.        The meaning is that the NG3 connection/tunnel should be        released, but the UE's context in the SMF1 42 should be kept and        transferred from Active to Idle. This message includes the UE        temporary/permanent ID, the indication for the specific session        ID (e.g. session #1) and other parameters.    -   Step (4) The SMF1 42 sends a NG3 release request message to the        UPF1 46. This message includes the UE temporary/permanent ID, an        indication for the specific session ID (e.g. session #1) and        other parameters. The UPF1 46 releases all associated resources        to session #1 with regard to the NG3 reference point.    -   Step (5) The UPF1 46 sends a NG3 release response message to the        SMF1 42 including the UE ID, the session ID and other        parameters. At this point, the SMF1 42 change session status        from Active to Idle.    -   Step (6) The SMF1 42 sends a NG3 release response message to the        CCNF 32 including the UE ID, the session ID and other        parameters.    -   Step (7) The CCNF 32 has two alternatives depending on the        number of remaining active sessions.    -   Option (7.a) If this is not the last active session, the CCNF 32        sends a UE connection release command message to the (R)AN node        30 including the UE ID, the session ID and other parameters.        This message has information that indicates that only session #1        is to be deactivated.    -   Option (7.b) If this is the last active session, the CCNF 32        sends a UE context release command message to the (R)AN node 30        including the UE ID, the session ID and other parameters. This        message has information that indicates that only session #1 is        to be released.    -   Step (8) There are 2 alternatives possible depending on the        number of remaining active sessions and instruction from the        CCNF 32:    -   Option (8.a) The (R)AN node 30 performs a RRC connection        modification procedure. For this purpose the (R)AN node 30 sends        a RRC connection reconfiguration message to the UE 34 in order        to release an associated data radio connection to the session        #1. Other active radio connection(s) are not released.    -   Option (8.b) The (R)AN node 30 performs a RRC connection release        procedure if this is the last existing radio connection for the        UE 34. For this purpose the (R)AN node 30 sends a RRC connection        reconfiguration message to the UE 34 in order to release an        associated radio connection to the session #1.    -   If Option (8.a) has been performed, the UE 34 transfers the        state of the corresponding session (e.g. session #1) from Active        to Idle state.    -   It is important to mention that in the UE 34, the session #1        context is not deleted, but kept in Idle state, while other        session states may be in Active states.    -   Step (9) The (R)AN node 30 sends either (9.a) a UE connection        release complete message to the CCNF 32 or (9.b) a UE context        release complete message to the CCNF 32.    -   Assuming that the deactivated session #1 is not the last active        sessions, FIG. 12 shows at the bottom that the radio connection        and the NG3 connection/tunnel for session #2 are kept after        performing the deactivation procedure for session #1.

Solution 4.2: Session Deactivation Initiated by the UPF

FIG. 13 describes an alternative solution where the session deactivationprocedure is initiated by the UPF of the corresponding session. Thissolution proposes that each UPF manages an inactivity timer, which canbe called a “session inactivity timer”. This timer can be configured bythe SMF when a session is activated, e.g. step (12) in FIG. 7 or in FIG.8 can contain a “session inactivity timer” parameter. The UPF measuresthe time for which there are no DL or UL data exchanged. When themeasured time for data inactivity reaches the value of the parameter“session inactivity timer”, the UPF triggers a UP connection releaseprocedure.

As a starting point, the UE 34 is in MM Ready state and session #1 andsession #2 are activated. This is shown by the thick arrowscorresponding to 2 radio connections and 2 NG3 connections between the(R)AN node 30 and, the UPF1 46 and the UPF2 48 correspondingly.

The steps in FIG. 13 are described as follows:

-   -   Step (1) The UPF1 46 detects that the session inactivity timer        expires. It means that the UPF1 46 has determined that no data        has been transmitted in the UL or DL for a given period of time        denoted as the “inactivity timer” for session #1.    -   Step (2) The UPF1 46 initiates a release request procedure for        the UP connection towards the (R)AN. The UPF1 46 sends a NG3        release request message (or similar message e.g. a Deactivate        session request or a Release connection request) to the SMF1 42.        This message can contain a UE ID, a session ID, a cause value        and other parameters.    -   Step (3) The SMF1 42 initiates a UP connection release        procedure. The SMF1 42 sends a NG3 release request message (or a        similar message e.g. a Deactivate session request or a Release        connection request) to the CCNF 32. This message can contain the        UE ID, the session ID, the cause value and other parameters.    -   Step (4) The CCNF (e.g. MMF) 32 has 2 options depending on the        number of remaining active sessions (or radio connections)    -   Option (4.a) If this is not the last active session, the CCNF 32        initiates a UE connection release procedure towards the (R)AN        node 30. The CCNF 32 sends a UE connection release request        message to the (R)AN node 30. This message includes a UE        temporary/permanent ID, indication which session has to be        deactivated (e.g. session #1) and other parameters.    -   Option (4.b) If this is the last active session (e.g. there are        no more active sessions and corresponding radio or NG3        connections), the CCNF 32 initiates a UE context release        procedure. This would enforce change of the mobility (MM) state        from Ready to Standby.    -   Step (5) There are 2 alternatives possible depending on the        number of remaining active sessions and instruction from the        CCNF 32:    -   Option (5.a) The (R)AN node 30 performs a RRC connection        modification procedure. For this purpose the (R)AN node 30 sends        a RRC connection reconfiguration message to the UE 34 in order        to release an associated radio connection to the session #1. It        is assumed that the radio data bearer/connection to be released        have 1-to-1 association with the NAS SM context corresponding        with the session to be deactivated. Also, the radio signalling        over RRC contains an indication about the session to be        deactivated (session ID). Other active radio connection(s) are        not released.    -   Option (5.b) The (R)AN node 30 performs a RRC connection release        procedure if this is the last existing radio connection for the        UE 34. For this purpose the (R)AN node 30 sends a RRC connection        reconfiguration message to the UE 34 in order to release an        associated radio connection to the session #1.    -   If Option (5.a) has been performed, the UE 34 transfers the        state of the corresponding session (e.g. session #1) from Active        to Idle state.    -   Step (6) The (R)AN node 30 sends either (6.a) a UE connection        release complete message to the CCNF 32 or (6.b) a UE context        release complete message to the CCNF 32.    -   Step (7) The CCNF 32 replies to the UP connection release        procedure in step (3). The CCNF 32 sends a NG3 release response        message (or a similar message e.g. a Deactivate session response        or a Release connection response) to the SMF1 42. This message        can contain the UE ID, the session ID, the cause value and other        parameters.    -   Step (8) The SMF1 42 replies to the UP connection release        procedure in step (2). The SMF1 42 sends a NG3 release response        message (or a similar message e.g. a Deactivate session response        or a Release connection response) to the UPF1 46. This message        can contain the UE ID, the session ID, the cause value and other        parameters.    -   At this point, the SMF1 42 change session status from Active to        Idle.

Another alternative to solution 4.2 would be to use a NAS SM Sessiondeactivation procedure between the SMF1 42 and the UE 34. This procedurecan be used by the SMF1 42 to inform the UE 34 about the SM contextdeactivation, which results in changing the session SM state in the UE34 from Active to Idle. Such a NAS SM procedure can be initiated by theSMF1 42 in parallel to steps (3), (4) and (5) in FIG. 13 .

Solution 4.3: Session Deactivation Initiated by the UE

This is another alternative way of session deactivation (i.e. release ofUP connection) where the procedure is initiated by the UE 34. Since theUE 34 can be aware about the Applications running on higher layers, theUE 34 may know whether an application has finished with the datatransfer. If such an indication is available from the higher layers tothe NAS layer, then the NAS layer in the UE 34, specifically the NAS SMpart, can initiate a session deactivation procedure towards the NG CN.

In a particular example, if an Application associated with session Aindicates to the NAS SM instance in the UE 34 that such an applicationdoes not need any more UP connections, or the NAS SM instance is awareby any means that the active UP connection is not used, the UE's NAS SMinstance for session A can initiate session deactivation proceduretowards the NG CN. The following steps can be performed:

-   -   Step (1) The UE 34 initiates a NAS SM Session deactivation        procedure towards the SMF1 42 in order to inform the SMF1 42        that the UP connection can be released. The UE 34 generates a        NAS SM Deactivation session request message and sends it over        NAS signaling towards the NG CN. This message includes besides        the usual NAS SM parameters an indication about the UP        connection deactivation and session ID. The NG CN processes the        message and forwards it to the corresponding SMF1 42.    -   Step (2) The SMF1 42 initiates a NG3 release procedure towards        the UPF1 46.    -   Step (3) The SMF1 42 initiates a NG3 release request (or a        Deactivate session request) procedure towards the CCNF (e.g.        MMF) 32.    -   Step (4) The MMF 32 processes the NG3 release request message        from the SMF1 42. The MMF 32 initiates the NG3 release procedure        (or the Deactivate session procedure) towards the (R)AN node 30.    -   Step (5) The (R)AN node 30 performs the NG3 release procedure        (or the Deactivate session procedure) towards the UE 34, e.g.        via a RRC connection modification procedure. The (R)AN node 30        also modifies the context of the UE 34 by deleting the NG3        parameters of the corresponding UPF node. The (R)AN node 30        replies to the MMF 32 with the result of the NG3 release        procedure.    -   Step (6) The MMF 32 changes the status of the corresponding        session to Idle. The MMF 32 replies to the SMF1 42 with the        result of the NG3 release procedure.    -   Step (7) The SMF1 42 acknowledges the NAS SM Session        deactivation request message in step (1).

Please note that the steps (2)-(6) above are similar to steps (3)-(7) insolution 4.2 shown in FIG. 13 . The major difference from solution 4.3compared to 4.2 is the NAS SM Session deactivation procedure performedbetween the UE 34 and the SMF1 42.

The descriptions below apply to all solutions described in thisdocument.

The examples above describe solutions for the activation or deactivationof a single session. However, it is also possible to activate/deactivateseveral sessions simultaneously by including several Session IDs in thecorresponding messages. The activation of several sessionssimultaneously can be beneficial in case of multiple PDU sessions perdata network, where it is assumed that the same SMF controls themultiple PDU sessions. In one alternative, the SMF decides whether toactivate a single PDU session (e.g. to which DL data arrives) or toactivate some or even all PDU session controlled by this SMF (whichprobably means some or all PDU sessions toward a particular networkslice or data network).

Please note that the signalling to/from the (R)AN node 30 over NG2interface can be terminated at a common front-end NG2 terminationfunctionality in the CCNF 32. The common front-end NG2 functionality canroute/forward the content of the NG2 message to the MMF 32 and/or theSMF2 44. Further, it is possible that the (R)AN node 30 sends 2different NG2 messages, a separate message to the MMF 32 and a separatemessage to the SMF2 44. The message to the MMF 32 may request anMM-specific action or can confirm the successful establishment/releaseof a data radio connection. The message to the SMF2 44 can mainlycontain (R)AN node UP NG3-related information (e.g. tunnellinginformation like the IP address of UPF2 48 and/or the GTP TEID).

Please note that all figures above show scenarios of a single UPF persession. However, this document is applicable to scenarios with multipledifferent UPFs served by a single SMF. In such case it can be assumedthat there are multiple PDU sessions for the same data network. Thesessions can be activated independently for each UPF. In such case, anactivated session exists to another UPF served by the same SMF2 44 (i.e.the UE 34 is in Ready mobility state and the SMF2 44 is in Activesession state). Then the SMF2 44 doesn't need to initiate pagingprocedure, but instead the SMF2 44 can either modify existing session orinitiate the activation on new UP session. For this purpose the SMrequests the CCNF (MMF) 32 to add a new UP session including the UPF2 48information.

Co-location of control plane functions like the MMF and the SMF in acommon control plane functional entity is possible.

The proposed solution is based on the following principles:

-   -   The session management function (SMF) and mobility management        function (MMF) are split in different network functions. In the        particular case of UE registered with multiple network slice        instances, the UE would be served by multiple SMFs, i.e.        multiple PDU session are established.    -   Multiple PDU sessions (to the same or to different network        slices) are established for a given UE. A PDU session can be in        Idle state or Active state.    -   A UP connection (including data radio connection and NG3 tunnel        establishing) can be activated for a single PDU session. UP        connections for other PDU sessions (to the same or to other        network slices) can be activated/deactivated independently.    -   The procedures for PDU session activation and deactivation are        proposed, meaning:    -   PDU session activation is the transition to “Active” session        state in the SMF and the UP connection is established;    -   PDU session deactivation is the transition to “Idle” session        state in the SMF and the UP connection is released.

General Nodes Description

The description below applies to all solutions described in thisdocument.

UE Impact

Please note that the solutions in this document are mostly describedincluding the UE as NG UE, but it is also possible to apply the solutionto 2G, 3G and 4G access system, i.e. when the UE is 2G/3G/4G UE.

According to the above described example embodiments, the UE 34 ismodified to be able to handle the signaling to/from the (R)AN and CNfunctional entities (e.g. (R)AN node, MMF, SMF). In addition, the UE 34is able to receive, process and transmit the corresponding informationto the (R)AN and CN functional entities. The UE 34 can be describedschematically via the block diagram as in FIG. 14 .

FIG. 14 is a block diagram illustrating the main components of the userequipment (UE) 34 shown in e.g. FIG. 1 (where it is denoted ‘NG UE’). Asshown, the UE 34 has a transceiver circuit 50 that is operable totransmit signals to and to receive signals from a radio access networknode 30 via one or more antenna 52. Such radio access network node 30(denoted ‘NG (R)AN’ in FIG. 1 , ‘RAN’ in FIG. 2 , and ‘AN’ in FIG. 4 )may comprise a base station and/or any other suitable accesspoint/transmission point. The UE 34 has a controller 54 to control theoperation of the UE 34. The controller 54 is associated with a memory 56and is coupled to the transceiver circuit 50. The UE 34 may have all theusual functionality of a conventional mobile device/mobile telephone(such as a user interface) and this may be provided by any one or anycombination of hardware, software and firmware, as appropriate. Softwaremay be pre-installed in the memory 56 and/or may be downloaded via thetelecommunication network or from a removable data storage device (RMD),for example.

The controller 54 controls overall operation of the UE 34 by, in thisexample, program instructions or software instructions stored within thememory 56. As shown, these software instructions include, among otherthings, an operating system 58, a communication control module 60, and atransceiver control module 62 (shown as forming part of thecommunication control module 60).

The communication control module 60 controls the communication betweenthe UE 34 and the base station/access node of the (R)AN. Thecommunications control module 60 also controls the separate flows ofcontrol data (Control Plane) and user data (User Plane, both uplink anddownlink) that are to be transmitted to the base station/access node andother nodes (via the base station/access node) such as the MobilityManagement Function (MMF) and the Session Management Function (SMF).

MMF/SMF Impact

According to the above described example embodiments, the MobilityManagement Function (MMF) or Session Management Function (SMF) ismodified/extended to be able to behave according to the proposedsolution(s). The MMF or the SMF can be described schematically via theblock diagram as in FIG. 15 .

FIG. 15 is a block diagram illustrating the main components of theMobility Management Function (MMF)/Session Management Function (SMF)node shown in e.g. FIG. 1 . Although the MMF and the SMF are shown aspart of a combined control function entity, their functionalities may beimplemented in separate nodes.

As shown, the MMF/SMF has a transceiver circuit 64 and a networkinterface 66 for transmitting signals to and for receiving signals fromother network nodes (including the UE 34). The MMF/SMF has a controller68 to control the operation of the MMF/SMF node. The controller 68 isassociated with a memory 70. Software may be pre-installed in the memory70 and/or may be downloaded via the communication network or from aremovable data storage device (RMD), for example. The controller 68 isconfigured to control the overall operation of the MMF/SMF by, in thisexample, program instructions or software instructions stored within thememory 70. As shown, these software instructions include, among otherthings, an operating system 72, a communication control module 74, and atransceiver control module 76 (shown as forming part of thecommunication control module 74).

The communication control module 74 controls the communication betweenthe MMF/SMF and other network entities that are connected to the MMF/SMF(e.g. the base station/access node, and the UE 34 when connected to abase station/access node).

SUMMARY

Beneficially, the above described example embodiments include, althoughthey are not limited to, one or more of the following functionalities.

1) The UE is able to link a data radio connection activation ordeactivation procedures with an existing PDU session management contextin the UE.

-   -   a. Such a linkage in the UE is based on a session ID indication        carried in the related signalling from the SMF to the UE.

2) The user plane connection deactivation is performed by the sessionmanagement function in the NG CN triggered:

-   -   a. either by the user plane function in the core network; or    -   b. by the UE via NAS SM signaling.

It can be seen that the above example embodiments describe a method forindependent activation or deactivation of a user plane connection perPDU session or network slice, the method comprising:

1) The activation or deactivation of a user plane connection isinitiated from the SMF based on:

-   -   a. Trigger from the UPF (due to arriving of DL data for session        activation or due to timer expiration for session deactivation);    -   b. Trigger from the UE (due to UL data transmission for session        activation, or due to no need of UP connection for session        deactivation).

2) The control plane session management function, mobility managementfunction, access network and terminal use a session ID as a reference IDto refer to the same session.

Benefits

It can be seen that the above embodiments provide a number of benefits,including, but not limited to:

(1) The number of active NG3 connections is limited even if there aremultiple user plane functions instantiated/configured for a UE, whichalso limits the signaling over radio and NG2 and NG3 interface in caseof UE mobility.

(2) If the UE receives or transmits data over single particular session,the user plane connection only to this particular session is activated,which reduces the signaling for connection establishment for othersessions if frequent mobility state changes between Standby and Readystates happen.

MODIFICATIONS AND ALTERNATIVES

Detailed example embodiments have been described above. As those skilledin the art will appreciate, a number of modifications and alternativescan be made to the above example embodiments whilst still benefitingfrom the inventions embodied therein. By way of illustration only anumber of these alternatives and modifications will now be described.

In the above description, the UE and the MMF/SMF node are described forease of understanding as having a number of discrete modules (such asthe communication control modules). Whilst these modules may be providedin this way for certain applications, for example where an existingsystem has been modified to implement the invention, in otherapplications, for example in systems designed with the inventivefeatures in mind from the outset, these modules may be built into theoverall operating system or code and so these modules may not bediscernible as discrete entities. These modules may also be implementedin software, hardware, firmware or a mix of these.

Each controller may comprise any suitable form of processing circuitryincluding (but not limited to), for example: one or more hardwareimplemented computer processors; microprocessors; central processingunits (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits;internal memories/caches (program and/or data); processing registers;communication buses (e.g. control, data and/or address buses); directmemory access (DMA) functions; hardware or software implementedcounters, pointers and/or timers; and/or the like.

In the above example embodiments, a number of software modules aredescribed. As those skilled in the art will appreciate, the softwaremodules may be provided in compiled or un-compiled form and may besupplied to the UE and the MMF/SMF node as a signal over a computernetwork, or on a recording medium. Further, the functionality performedby part or all of this software may be performed using one or morededicated hardware circuits. However, the use of software modules ispreferred as it facilitates the updating of the UE and the MMF/SMF nodein order to update their functionalities.

Various other modifications will be apparent to those skilled in the artand will not be described in further detail here.

List of Abbreviations 3GPP: 3rd Generation Partnership Project

AS: Access Stratum (use similar to RRC signaling in this document)

CCF: Core Control Functions CCNF: Common Control Network Functions CPF:Control Plane Function

NB, eNB: Node B, evolved Node B (but can also be any ‘RAN node’implementing 2G, 3G, 4G or future 5G technology)E-UTRAN: Evolved Universal Terrestrial Radio Access Network (also usedas EUTRAN)

GGSN: Gateway GPRS Support Node GPRS: General Packet Radio ServiceHPLMN: Home Public Land Mobile Network HSS: Home Subscriber Server

IE: Informational Element (used as part of a signalling message)

MME: Mobility Management Entity MMF: Mobility Management Function MNO:Mobile Network Operator NAS: Non Access Stratum NFV: Network FunctionVirtualization NNSF: NAS/Network Node Selection Function NSI: NetworkSlice Instances PCF: Policy Control Function PCRF: Policy and ChargingRules Function PGW: Packet Data Network Gateway PSM: Power Saving ModeRAU: Routing Area Update RNC: Radio Network Controller RRC: RadioResource Control PLMN: Public Land Mobile Network SCNF: Slice-specificControl Plane Network Functions SMF: Session Management Function SGSN:Serving GPRS Support Node SGW: Serving Gateway TAU: Tracking Area UpdateUE: User Equipment

UPF: User Plane Function (any UP function used for policy/QoSenforcement, mobility, UE's IP anchor, similar to SGW/PGW in EPC)

UTRAN: UMTS Terrestrial Radio Access Network VPLMN: Visited Public LandMobile Network

This application is based upon and claims the benefit of priority fromEuropean Patent application No. EP 16185042.5, filed on Aug. 19, 2016,the disclosure of which is incorporated herein in its entirety byreference.

1. A method performed in a User Equipment (UE), the method comprising:sending, to a second core network node, a first request so that a UserPlane resource is released; and receiving a Radio Resource Configuration(RRC) message, wherein the first request includes at least one sessionID, and the at least one session ID corresponds to a first core networknode.
 2. The method according to claim 1, wherein the RRC message isreceived to release an access node resource.
 3. The method according toclaim 1, wherein the User Plane resource is released by the first corenetwork node.
 4. The method according to claim 1, wherein the first corenetwork node is a session management function (SMF).
 5. The methodaccording to claim 1, wherein the second core network node is a mobilitymanagement node.
 6. A method performed in a second core network node,the method comprising: receiving, from a User Equipment (UE), a firstrequest so that a User Plane resource is released; and sending, to afirst core network node, the first request; wherein the first requestincludes at least one session ID, and the at least one session IDcorresponds to the first core network node.
 7. The method according toclaim 6, further comprising: receiving, from the first core networknode, a protocol data unit (PDU) session release command; and sending,to an access node, information including the PDU session releasecommand.
 8. The method according to claim 6, wherein the User Planeresource is released by the first core network node.
 9. The methodaccording to claim 6, wherein the first core network node is a sessionmanagement function (SMF).
 10. The method according to claim 6, whereinthe second core network node is a mobility management node.
 11. A methodperformed in a first core network node, the method comprising:receiving, from a second core network node, a first request; andreleasing a User Plane resource after receiving the first request;wherein the first request includes at least one session ID, and the atleast one session ID corresponds to the first core network node.
 12. Themethod according to claim 11, further comprising: sending, to the secondcore network node, a protocol data unit (PDU) session release command.13. The method according to claim 11, wherein the first core networknode is a session management function (SMF).
 14. The method according toclaim 11, wherein the second core network node is a mobility managementnode.
 15. A User Equipment (UE) comprising: a memory having storedtherein program instructions; and at least one processor that whenexecuting the program instructions is configured to: send, to a secondcore network node, a first request so that a User Plane resource isreleased and receive a Radio Resource Configuration (RRC) message,wherein the first request includes at least one session ID, wherein theat least one session ID corresponds to a first core network node. 16.The user equipment (UE) according to claim 15, wherein the RRC messageis received to release an access node resource.
 17. The user equipment(UE) according to claim 15, wherein the User Plane resource is releasedby the first core network node.
 18. The user equipment (UE) according toclaim 15, wherein the first core network node is a session managementfunction (SMF).
 19. The user equipment (UE) according to claim 15,wherein the second core network node is a mobility management node. 20.A second core network node comprising: a memory having stored thereinprogram instructions; and at least one processor that when executing theprogram instructions is configured to: receive, from a User Equipment(UE), a first request so that a User Plane resource is released; andsend, to a first core network node, the first request; wherein the firstrequest includes at least one session ID, and the at least one sessionID corresponds to the first core network node.
 21. The second corenetwork node according to claim 20, wherein the at least one processoris further configured to execute the program instructions to receive,from the first core network node, a protocol data unit (PDU) sessionrelease command, and send, to an access node, information including thePDU session release command.
 22. The second core network node accordingto claim 20, wherein the User Plane resource is released by the firstcore network node.
 23. The second core network node according to claim20, where in the first core network node is a session managementfunction (SMF).
 24. The second core network node according to claim 20,wherein the second core network node is a mobility management node. 25.A first core network node comprising: a memory having stored thereinprogram instructions; and at least one processor that when executing theprogram instructions is configured to: receive, from a second corenetwork node, a first request; and release a User Plane resource afterreceiving the first request; wherein the first request includes at leastone session ID, and the at least one session ID corresponds to the firstcore network node.
 26. The first core network node according to claim25, wherein the at least one processor is further configured to executethe program instructions to send, to the second core network node, aprotocol data unit (PDU) session release command.
 27. The first corenetwork node according to claim 25, wherein the first core network nodeis a session management function (SMF).
 28. The first core network nodeaccording to claim 25, wherein the second core network node is amobility management node.